Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 79.46%. Comparing base (ae5eb17) to head (6abdd2a).

@@           Coverage Diff           @@
##           master    #1504   +/-   ##
=======================================
  Coverage   79.46%   79.46%           
=======================================
  Files         121      121           
  Lines        5409     5410    +1     
=======================================
+ Hits         4298     4299    +1     
  Misses       1111     1111           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Only thing im unsure of is the migration generated seems to be duplicating changes? It seems to be converting the id of some fields to BigAutoField despite that already being in the previous squashed migration? I cant imagine it would cause any issues but not really sure whats going on with that.
Let me know if I should make any changes.

Code looks good to me :) That migration is a bit strange yeah, maybe @hmpf can shed some light on what's happening there

Can you add one or more tests?

• RES should reopen a closed incident
• only source systems can restart incidents
• Defined behaviour on RES an already open incident?

Agree about the migrations, the change to BigAutoField should already have happened . On Tuesday I hope to be able to check this properly.

Do python manage.py dbshell against prod and dev database. In dbshell run select * from django_migrations where app = 'argus_incident';.

You should have this line (first column may be different, last column deffo different)

 89 | argus_incident | 0009_use_bigautofield_on_quickly_growing_tables | 2025-05-16 08:23:36.499823+02

If not in prod db I'll see if I can do some experiments (with your help) next week, we might need a release that canonicalizes the squashed migrations (=deletes the old ones, needs manual rewrite of the new migrations). If not in dev: nuke the dev database and migrate to version 1.37.0 and check again before you migrate to 2.0.0.

Also do \d argus_incident_incident and check that the Type of the id field is already bigint:

       Column       |           Type           | Collation | Nullable |                       Default                       
--------------------+--------------------------+-----------+----------+-----------------------------------------------------
 id                 | bigint                   |           | not null | nextval('argus_incident_incident_id_seq'::regclass)

Can you add one or more tests?

I would also like to see a test for restarting an ended incident and then ending it again.

* Defined behaviour on RES an already open incident?

This should simply post the event without changing anything about the incident itself.

Agree about the migrations, the change to BigAutoField should already have happened . On Tuesday I hope to be able to check this properly.

Do python manage.py dbshell against prod and dev database. In dbshell run select * from django_migrations where app = 'argus_incident';.

You should have this line (first column may be different, last column deffo different)

 89 | argus_incident | 0009_use_bigautofield_on_quickly_growing_tables | 2025-05-16 08:23:36.499823+02

If not in prod db I'll see if I can do some experiments (with your help) next week, we might need a release that canonicalizes the squashed migrations (=deletes the old ones, needs manual rewrite of the new migrations). If not in dev: nuke the dev database and migrate to version 1.37.0 and check again before you migrate to 2.0.0.

Also do \d argus_incident_incident and check that the Type of the id field is already bigint:

       Column       |           Type           | Collation | Nullable |                       Default                       
--------------------+--------------------------+-----------+----------+-----------------------------------------------------
 id                 | bigint                   |           | not null | nextval('argus_incident_incident_id_seq'::regclass)

Ok so have investigated this some more and it actually seems to be a small issue with the squashed migration. Firstly if I just checkout to master with a blank db and make migrations it makes the same changes for the ID's (except what I added of course), i assume there should be no detected changes. What I think has happened is that originally the ID fields were being autocreated (not defined in model) but then explicitly defined as bigints in 10bc007. So in migration 0001_initial it does fields=[("id", models.AutoField(auto_created=True, primary_key=True, serialize=False, verbose_name="ID")) but after being explicitly defined as bigint the alterfield in 0009 does field=models.BigAutoField(primary_key=True, serialize=False),. But in the squashed migration its treating the id's as autocreated even though they are explicitly defined in the model to be bigints. Im not sure how the squashed migration is made but changing

('id', models.BigAutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')),

to

('id', models.BigAutoField(primary_key=True, serialize=False),

in the squashed migration stops makemigrations from detecting changes.
DEFAULT_AUTO_FIELD is just AutoField in base.py so doesnt seem to make sense for a BigAutoField to be autocreated.
I suppose this could somehow be an issue on my end or im misunderstanding things haha but this is what I think is going on. I suppose this would need a separate PR to fix the squashed migration?

Ok have now

• Fixed the issues with the code
• Made a unit test to restart a closed incident then close it again
• Fixed the migration
• Small change to docs

Let me know if you want more tests/changes to what I made, the test does have very similar functionality to the test for reopening i'm not sure if that should be combined. fixed, seems ok now

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud